પ્રોએક્ટિવ પાઇપલાઇન: વૈશ્વિક પ્રેક્ષકો માટે જાવાસ્ક્રિપ્ટ પર્ફોર્મન્સનું ઓટોમેશન

ડિજિટલ અર્થતંત્રમાં, ગતિ એ એક સાર્વત્રિક ભાષા છે. ટોક્યો, લંડન, કે સાઓ પાઉલોમાં રહેતા વપરાશકર્તાની એક જ અપેક્ષા હોય છે: એક ઝડપી, સરળ ડિજિટલ અનુભવ. જ્યારે કોઈ વેબ એપ્લિકેશન અટકી જાય, ફ્રીઝ થઈ જાય, અથવા લોડ થવામાં સેકન્ડો લે, ત્યારે તે માત્ર એક અસુવિધા નથી; તે એ અપેક્ષાનું ઉલ્લંઘન છે. આ વપરાશકર્તાની સગાઈ, રૂપાંતરણ દરો, અને બ્રાન્ડ પ્રતિષ્ઠાનો શાંત હત્યારો છે. વર્ષોથી, પર્ફોર્મન્સ વિશ્લેષણ એક પ્રતિક્રિયાશીલ શિસ્ત રહ્યું છે—વપરાશકર્તાઓ ફરિયાદ કરવાનું શરૂ કરે પછી Chrome DevTools માં ઊંડાણપૂર્વક તપાસ કરવી. સતત ડિપ્લોયમેન્ટ અને વૈશ્વિક વપરાશકર્તા આધારની દુનિયામાં આ અભિગમ હવે ટકી શકે તેમ નથી.

પ્રોએક્ટિવ પાઇપલાઇનમાં આપનું સ્વાગત છે. આ મેન્યુઅલ, એડ-હોક પર્ફોર્મન્સ તપાસથી મોનિટરિંગ અને અમલીકરણની વ્યવસ્થિત, સ્વયંસંચાલિત અને સતત પ્રક્રિયા તરફનું એક પેરાડાઈમ શિફ્ટ છે. તે તમારા વિકાસ જીવનચક્રના મુખ્ય સિદ્ધાંત તરીકે પર્ફોર્મન્સને સમાવિષ્ટ કરવા વિશે છે, જેમ કે યુનિટ ટેસ્ટિંગ અથવા સુરક્ષા સ્કેનિંગ. જાવાસ્ક્રિપ્ટ પર્ફોર્મન્સ પ્રોફાઇલિંગને સ્વયંસંચાલિત કરીને, તમે રિગ્રેશન્સને ઉત્પાદનમાં પહોંચતા પહેલા જ પકડી શકો છો, ડેટા-આધારિત ઓપ્ટિમાઇઝેશન નિર્ણયો લઈ શકો છો, અને ખાતરી કરી શકો છો કે દરેક વપરાશકર્તા, તેમના સ્થાન અથવા ઉપકરણને ધ્યાનમાં લીધા વિના, શ્રેષ્ઠ સંભવિત અનુભવ મેળવે છે.

આ વ્યાપક માર્ગદર્શિકા તમને તમારી પોતાની સતત પર્ફોર્મન્સ મોનિટરિંગ પાઇપલાઇન બનાવવાના કારણો, શું અને કેવી રીતે કરવું તે વિશે માર્ગદર્શન આપશે. અમે સાધનોનું અન્વેષણ કરીશું, મહત્વપૂર્ણ મેટ્રિક્સને વ્યાખ્યાયિત કરીશું, અને આ તપાસને સીધી તમારી CI/CD વર્કફ્લોમાં કેવી રીતે એકીકૃત કરવી તેના વ્યવહારુ ઉદાહરણો પ્રદાન કરીશું.

મેન્યુઅલ પ્રોફાઇલિંગથી ઓટોમેટેડ ઇનસાઇટ્સ સુધી: એક આવશ્યક ઉત્ક્રાંતિ

મોટાભાગના ફ્રન્ટ-એન્ડ ડેવલપર્સ તેમના બ્રાઉઝરના ડેવલપર ટૂલ્સમાં પર્ફોર્મન્સ અને લાઇટહાઉસ ટેબ્સથી પરિચિત છે. આ કોઈ ચોક્કસ પેજ પરની સમસ્યાઓનું નિદાન કરવા માટે અત્યંત શક્તિશાળી સાધનો છે. પરંતુ માત્ર તેમના પર આધાર રાખવો એ ગગનચુંબી ઇમારતની માળખાકીય અખંડિતતા સુનિશ્ચિત કરવા માટે વર્ષમાં એકવાર માત્ર એક જ સપોર્ટ બીમ તપાસવા જેવું છે.

મેન્યુઅલ પ્રોફાઇલિંગની મર્યાદાઓ

• તે પ્રતિક્રિયાશીલ છે, સક્રિય નથી: મેન્યુઅલ તપાસ સામાન્ય રીતે ત્યારે થાય છે જ્યારે કોઈ સમસ્યા પહેલેથી જ ઓળખાઈ ગઈ હોય. તમે આગ બુઝાવી રહ્યા છો, તેને અટકાવી રહ્યા નથી. જે સમય સુધીમાં કોઈ ડેવલપર ધીમી ગતિની તપાસ કરવા માટે DevTools ખોલે છે, ત્યાં સુધીમાં તમારા વપરાશકર્તાઓ પીડા અનુભવી ચૂક્યા હોય છે.
• તે અસંગત છે: તમને હાઇ-એન્ડ ડેવલપમેન્ટ મશીન પર જે પરિણામો મળે છે, જે ઝડપી ઓફિસ નેટવર્ક સાથે જોડાયેલ હોય, તે મધ્યમ-શ્રેણીના મોબાઇલ ઉપકરણ પર સ્પોટી કનેક્ટિવિટીવાળા પ્રદેશમાં વપરાશકર્તા જે અનુભવે છે તેનાથી તદ્દન અલગ હોય છે. મેન્યુઅલ પરીક્ષણોમાં નિયંત્રિત, પુનરાવર્તિત વાતાવરણનો અભાવ હોય છે.
• તે સમય માંગી લે તેવું છે અને સ્કેલેબલ નથી: સંપૂર્ણ પર્ફોર્મન્સ પ્રોફાઇલિંગ માટે નોંધપાત્ર સમય અને કુશળતાની જરૂર પડે છે. જેમ જેમ એપ્લિકેશનની જટિલતા અને ટીમનું કદ વધે છે, તેમ ડેવલપર્સ માટે પર્ફોર્મન્સ રિગ્રેશન્સ માટે દરેક કમિટની મેન્યુઅલી તપાસ કરવી અશક્ય બની જાય છે.
• તે જ્ઞાનના અવરોધો બનાવે છે: ઘણીવાર, ટીમમાં માત્ર થોડા 'પર્ફોર્મન્સ ચેમ્પિયન્સ' જ જટિલ ફ્લેમ ચાર્ટ્સ અને ટ્રેસ ફાઇલોનું અર્થઘટન કરવાની ઊંડી કુશળતા ધરાવે છે, જે ઓપ્ટિમાઇઝેશન પ્રયાસો માટે અવરોધ ઊભો કરે છે.

ઓટોમેશન અને સતત મોનિટરિંગ માટેનો કેસ

પર્ફોર્મન્સ પ્રોફાઇલિંગને સ્વયંસંચાલિત કરવું તેને પ્રસંગોપાત ઓડિટમાંથી સતત પ્રતિસાદ લૂપમાં રૂપાંતરિત કરે છે. આ અભિગમ, જેને CI/CD સંદર્ભમાં ઘણીવાર "Synthetic Monitoring" કહેવામાં આવે છે, તે ગહન ફાયદાઓ પ્રદાન કરે છે.

• રિગ્રેશન્સને વહેલા પકડો: દરેક કમિટ અથવા પુલ રિક્વેસ્ટ પર પર્ફોર્મન્સ ટેસ્ટ ચલાવીને, તમે તરત જ તે ચોક્કસ ફેરફારને ઓળખી શકો છો જેણે ધીમી ગતિ લાવી છે. આ "shift left" અભિગમ સમસ્યાઓને સુધારવાને અનેકગણું સસ્તું અને ઝડપી બનાવે છે.
• પર્ફોર્મન્સ બેઝલાઇન સ્થાપિત કરો: ઓટોમેશન તમને તમારી એપ્લિકેશનના પર્ફોર્મન્સનો ઐતિહાસિક રેકોર્ડ બનાવવાની મંજૂરી આપે છે. આ ટ્રેન્ડ ડેટા વિકાસના લાંબા ગાળાના પ્રભાવને સમજવા અને ટેકનિકલ દેવા વિશે જાણકાર નિર્ણયો લેવા માટે અમૂલ્ય છે.
• પર્ફોર્મન્સ બજેટ લાગુ કરો: ઓટોમેશન "પર્ફોર્મન્સ બજેટ" ને વ્યાખ્યાયિત અને લાગુ કરવાનું શક્ય બનાવે છે—મુખ્ય મેટ્રિક્સ માટે થ્રેશોલ્ડનો સમૂહ જેને બિલ્ડ પાસ કરવા માટે મળવું આવશ્યક છે. જો કોઈ ફેરફાર Largest Contentful Paint (LCP) ને 20% ધીમું બનાવે છે, તો બિલ્ડ આપમેળે નિષ્ફળ થઈ શકે છે, જે રિગ્રેશનને ડિપ્લોય થતા અટકાવે છે.
• પર્ફોર્મન્સનું લોકશાહીકરણ કરો: જ્યારે પર્ફોર્મન્સ પ્રતિસાદ ડેવલપરના હાલના વર્કફ્લોમાં (દા.ત., પુલ રિક્વેસ્ટ પર ટિપ્પણી) આપમેળે પહોંચાડવામાં આવે છે, ત્યારે તે દરેક એન્જિનિયરને પર્ફોર્મન્સની માલિકી લેવા માટે સશક્ત બનાવે છે. તે હવે કોઈ નિષ્ણાતની એકમાત્ર જવાબદારી નથી.

સતત પર્ફોર્મન્સ મોનિટરિંગના મુખ્ય ખ્યાલો

સાધનોમાં ડૂબકી મારતા પહેલાં, કોઈપણ સફળ પર્ફોર્મન્સ મોનિટરિંગ વ્યૂહરચનાનો પાયો બનાવતા મૂળભૂત ખ્યાલોને સમજવું આવશ્યક છે.

ટ્રેક કરવા માટેના મુખ્ય પર્ફોર્મન્સ મેટ્રિક્સ ("શું")

તમે જે માપતા નથી તેને સુધારી શકતા નથી. જ્યારે ડઝનેક સંભવિત મેટ્રિક્સ છે, ત્યારે થોડા વપરાશકર્તા-કેન્દ્રિત મેટ્રિક્સ પર ધ્યાન કેન્દ્રિત કરવું એ સૌથી અસરકારક વ્યૂહરચના છે. Google ના કોર વેબ વાઇટલ્સ (Core Web Vitals) એક ઉત્તમ પ્રારંભિક બિંદુ છે કારણ કે તે વાસ્તવિક-વિશ્વના વપરાશકર્તા અનુભવને માપવા માટે ડિઝાઇન કરવામાં આવ્યા છે.

• Largest Contentful Paint (LCP): લોડિંગ પર્ફોર્મન્સને માપે છે. તે પેજ લોડ ટાઇમલાઇનમાં તે બિંદુને ચિહ્નિત કરે છે જ્યારે મુખ્ય સામગ્રી સંભવતઃ લોડ થઈ ગઈ હોય. સારો LCP 2.5 સેકન્ડ કે તેથી ઓછો હોય છે.
• Interaction to Next Paint (INP): ઇન્ટરેક્ટિવિટીને માપે છે. INP વપરાશકર્તાની ક્રિયાપ્રતિક્રિયાઓ પ્રત્યે પેજની એકંદર પ્રતિભાવશીલતાનું મૂલ્યાંકન કરે છે. તે તમામ ક્લિક્સ, ટેપ્સ અને કીબોર્ડ ક્રિયાપ્રતિક્રિયાઓની લેટન્સીનું નિરીક્ષણ કરે છે. સારો INP 200 મિલિસેકન્ડથી નીચે હોય છે. (INP એ માર્ચ 2024 માં First Input Delay (FID) ને Core Web Vital તરીકે બદલ્યું છે).
• Cumulative Layout Shift (CLS): દ્રશ્ય સ્થિરતાને માપે છે. તે વપરાશકર્તાઓ દ્વારા અનુભવાતા અણધાર્યા લેઆઉટ શિફ્ટનું પ્રમાણ માપે છે. સારો CLS સ્કોર 0.1 કે તેથી ઓછો હોય છે.

કોર વેબ વાઇટલ્સ ઉપરાંત, અન્ય નિર્ણાયક મેટ્રિક્સમાં શામેલ છે:

• Time to First Byte (TTFB): સર્વર પ્રતિસાદ સમયને માપે છે. તે એક પાયાનો મેટ્રિક છે કારણ કે ધીમો TTFB પછીના તમામ મેટ્રિક્સ પર નકારાત્મક અસર કરશે.
• First Contentful Paint (FCP): તે સમયને ચિહ્નિત કરે છે જ્યારે DOM સામગ્રીનો પ્રથમ ટુકડો રેન્ડર થાય છે. તે વપરાશકર્તાને પ્રથમ પ્રતિસાદ પૂરો પાડે છે કે પેજ ખરેખર લોડ થઈ રહ્યું છે.
• Total Blocking Time (TBT): FCP અને Time to Interactive (TTI) વચ્ચેનો કુલ સમય માપે છે જ્યાં મુખ્ય થ્રેડ ઇનપુટ પ્રતિભાવને રોકવા માટે પૂરતો લાંબો સમય અવરોધિત હતો. તે એક ઉત્તમ લેબ મેટ્રિક છે જે INP સાથે સારી રીતે સંબંધિત છે.

પર્ફોર્મન્સ બજેટ સેટ કરવું ("શા માટે")

પર્ફોર્મન્સ બજેટ એ સ્પષ્ટ મર્યાદાઓનો સમૂહ છે જેની અંદર તમારી ટીમ કામ કરવા માટે સંમત થાય છે. તે માત્ર એક લક્ષ્ય નથી; તે એક કડક મર્યાદા છે. બજેટ પર્ફોર્મન્સને "ચાલો તેને ઝડપી બનાવીએ" જેવા અસ્પષ્ટ ઉદ્દેશ્યથી તમારી એપ્લિકેશન માટે એક નક્કર, માપી શકાય તેવી જરૂરિયાતમાં રૂપાંતરિત કરે છે.

એક સરળ પર્ફોર્મન્સ બજેટ આના જેવું દેખાઈ શકે છે:

• LCP 2.5 સેકન્ડથી ઓછો હોવો જોઈએ.
• TBT 200 મિલિસેકન્ડથી ઓછો હોવો જોઈએ.
• કુલ જાવાસ્ક્રિપ્ટ બંડલનું કદ 250KB (gzipped) થી વધુ ન હોવું જોઈએ.
• લાઇટહાઉસ પર્ફોર્મન્સ સ્કોર 90 કે તેથી વધુ હોવો જોઈએ.

આ મર્યાદાઓને વ્યાખ્યાયિત કરીને, તમારી સ્વયંસંચાલિત પાઇપલાઇનમાં સ્પષ્ટ પાસ/ફેલ માપદંડ હોય છે. જો કોઈ પુલ રિક્વેસ્ટ લાઇટહાઉસ સ્કોરને 85 પર ઘટાડે છે, તો CI તપાસ નિષ્ફળ જાય છે, અને ડેવલપરને તરત જ સૂચિત કરવામાં આવે છે—પહેલાં કોડ મર્જ થાય.

પર્ફોર્મન્સ મોનિટરિંગ પાઇપલાઇન ("કેવી રીતે")

એક સામાન્ય સ્વયંસંચાલિત પર્ફોર્મન્સ પાઇપલાઇન આ પગલાં અનુસરે છે:

1. ટ્રિગર: એક ડેવલપર વર્ઝન કંટ્રોલ સિસ્ટમ (દા.ત., Git) માં નવો કોડ કમિટ કરે છે.
2. બિલ્ડ: CI/CD સર્વર (દા.ત., GitHub Actions, Jenkins, GitLab CI) કોડને ચેકઆઉટ કરે છે અને એપ્લિકેશન બિલ્ડ પ્રક્રિયા ચલાવે છે.
3. ડિપ્લોય અને ટેસ્ટ: એપ્લિકેશનને કામચલાઉ સ્ટેજિંગ અથવા પ્રિવ્યૂ પર્યાવરણમાં ડિપ્લોય કરવામાં આવે છે. પછી એક સ્વયંસંચાલિત સાધન આ પર્યાવરણ સામે પર્ફોર્મન્સ પરીક્ષણોનો સમૂહ ચલાવે છે.
4. વિશ્લેષણ અને ભારપૂર્વક કહેવું: સાધન પર્ફોર્મન્સ મેટ્રિક્સ એકત્રિત કરે છે અને તેને પૂર્વવ્યાખ્યાયિત પર્ફોર્મન્સ બજેટ સાથે સરખાવે છે.
5. રિપોર્ટ અને કાર્યવાહી: જો બજેટ પૂર્ણ થાય, તો તપાસ પાસ થાય છે. જો નહીં, તો બિલ્ડ નિષ્ફળ થાય છે, અને ટીમને રિગ્રેશન સમજાવતા વિગતવાર રિપોર્ટ સાથે એક ચેતવણી મોકલવામાં આવે છે.

ઓટોમેટેડ જાવાસ્ક્રિપ્ટ પ્રોફાઇલિંગ માટે આધુનિક ટૂલકિટ

કેટલાક ઉત્તમ ઓપન-સોર્સ સાધનો આધુનિક પર્ફોર્મન્સ ઓટોમેશનનો આધાર બનાવે છે. ચાલો સૌથી અગ્રણી સાધનોનું અન્વેષણ કરીએ.

Playwright અને Puppeteer સાથે બ્રાઉઝર ઓટોમેશન

Playwright (Microsoft તરફથી) અને Puppeteer (Google તરફથી) Node.js લાઇબ્રેરીઓ છે જે હેડલેસ Chrome, Firefox, અને WebKit બ્રાઉઝર્સને નિયંત્રિત કરવા માટે ઉચ્ચ-સ્તરની API પ્રદાન કરે છે. જ્યારે તે ઘણીવાર એન્ડ-ટુ-એન્ડ પરીક્ષણ માટે વપરાય છે, ત્યારે તે પર્ફોર્મન્સ પ્રોફાઇલિંગ માટે પણ અસાધારણ છે.

તમે તેનો ઉપયોગ જટિલ વપરાશકર્તા ક્રિયાપ્રતિક્રિયાઓને સ્ક્રિપ્ટ કરવા અને વિગતવાર પર્ફોર્મન્સ ટ્રેસ એકત્રિત કરવા માટે કરી શકો છો જેનું DevTools માં વિશ્લેષણ કરી શકાય છે. આ માત્ર પ્રારંભિક પેજ લોડ જ નહીં, પરંતુ ચોક્કસ વપરાશકર્તા પ્રવાસના પર્ફોર્મન્સને માપવા માટે યોગ્ય છે.

પર્ફોર્મન્સ ટ્રેસ ફાઇલ જનરેટ કરવા માટે Playwright નો ઉપયોગ કરીને એક સરળ ઉદાહરણ અહીં છે:

ઉદાહરણ: Playwright સાથે ટ્રેસ જનરેટ કરવું

• const { chromium } = require('playwright');
• (async () => {
• const browser = await chromium.launch({ headless: true });
• const page = await browser.newPage();
• // Start tracing, saving to a file.
• await page.tracing.start({ path: 'performance-trace.json', screenshots: true });
• await page.goto('https://your-app.com/dashboard');
• // Interact with the page to profile a specific action
• await page.click('button#load-data-button');
• await page.waitForSelector('.data-grid-loaded'); // Wait for the result
• // Stop tracing
• await page.tracing.stop();
• await browser.close();
• console.log('Performance trace saved to performance-trace.json');
• })();

તમે પછી `performance-trace.json` ફાઇલને Chrome DevTools પર્ફોર્મન્સ પેનલમાં લોડ કરી શકો છો જેથી તે વપરાશકર્તા ક્રિયાપ્રતિક્રિયા દરમિયાન શું થયું તેનું સમૃદ્ધ, ફ્રેમ-બાય-ફ્રેમ વિશ્લેષણ કરી શકાય. જ્યારે આ એક શક્તિશાળી નિદાન સાધન છે, ત્યારે આપણને સ્વયંસંચાલિત ભારપૂર્વક કહેવા માટે અન્ય સ્તરની જરૂર છે: Lighthouse.

વ્યાપક ઓડિટ માટે Google Lighthouse નો લાભ ઉઠાવવો

Lighthouse વેબ પેજની ગુણવત્તાનું ઓડિટ કરવા માટે ઉદ્યોગ-માનક ઓપન-સોર્સ સાધન છે. તે એક પેજ સામે પરીક્ષણોની શ્રેણી ચલાવે છે અને પર્ફોર્મન્સ, ઍક્સેસિબિલિટી, શ્રેષ્ઠ પ્રયાસો અને SEO પર એક રિપોર્ટ જનરેટ કરે છે. આપણી પાઇપલાઇન માટે સૌથી અગત્યનું, તેને પ્રોગ્રામેટિકલી ચલાવી શકાય છે અને પર્ફોર્મન્સ બજેટ લાગુ કરવા માટે રૂપરેખાંકિત કરી શકાય છે.

Lighthouse ને CI/CD પાઇપલાઇનમાં એકીકૃત કરવાનો શ્રેષ્ઠ માર્ગ Lighthouse CI સાથે છે. તે સાધનોનો એક સમૂહ છે જે Lighthouse ચલાવવાનું, બજેટ સામે પરિણામોની ખાતરી કરવાનું, અને સમય જતાં સ્કોર્સને ટ્રેક કરવાનું સરળ બનાવે છે.

શરૂ કરવા માટે, તમે તમારા પ્રોજેક્ટના રૂટમાં `lighthouserc.js` નામની રૂપરેખાંકન ફાઇલ બનાવશો:

ઉદાહરણ: lighthouserc.js રૂપરેખાંકન

• module.exports = {
• ci: {
• collect: {
• // વિકલ્પ 1: લાઇવ URL સામે ચલાવો
• // url: ['https://staging.your-app.com'],
• // વિકલ્પ 2: સ્થાનિક રીતે સર્વ કરેલા બિલ્ડ આઉટપુટ સામે ચલાવો
• staticDistDir: './build',
• startServerCommand: 'npm run start:static',
• },
• assert: {
• preset: 'lighthouse:recommended', // સમજદાર ડિફોલ્ટ્સ સાથે પ્રારંભ કરો
• assertions: {
• // કસ્ટમ એસર્શન્સ (તમારું પર્ફોર્મન્સ બજેટ)
• 'categories:performance': ['error', { minScore: 0.9 }], // સ્કોર >= 90 હોવો જોઈએ
• 'categories:accessibility': ['warn', { minScore: 0.95 }], // સ્કોર >= 95 હોવો જોઈએ
• 'core-web-vitals/largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
• 'core-web-vitals/total-blocking-time': ['error', { maxNumericValue: 200 }],
• },
• },
• upload: {
• target: 'temporary-public-storage', // શરૂ કરવાનો સૌથી સહેલો રસ્તો
• },
• },
• };

આ રૂપરેખાંકન સાથે, તમે તમારી કમાન્ડ લાઇન અથવા CI સ્ક્રિપ્ટમાંથી `lhci autorun` ચલાવી શકો છો. તે આપમેળે તમારું સર્વર શરૂ કરશે, સ્થિરતા માટે Lighthouse ને બહુવિધ વખત ચલાવશે, તમારા એસર્શન્સ સામે પરિણામો તપાસશે, અને જો બજેટ પૂર્ણ ન થાય તો નિષ્ફળ જશે.

સિન્થેટિક મોનિટરિંગ વિ. રિયલ યુઝર મોનિટરિંગ (RUM)

પર્ફોર્મન્સ મોનિટરિંગના બે મુખ્ય પ્રકારો વચ્ચેનો તફાવત સમજવો નિર્ણાયક છે.

• સિન્થેટિક મોનિટરિંગ (લેબ ડેટા): આ તે છે જેની આપણે ચર્ચા કરી રહ્યા છીએ—નિયંત્રિત, સુસંગત વાતાવરણ ("લેબ") માં સ્વયંસંચાલિત પરીક્ષણો ચલાવવા. તે CI/CD માટે યોગ્ય છે કારણ કે તે તમારા કોડ ફેરફારોની અસરને અલગ પાડે છે. તમે નેટવર્કની ગતિ, ઉપકરણનો પ્રકાર અને સ્થાન નિયંત્રિત કરો છો. તેની તાકાત સુસંગતતા અને રિગ્રેશન શોધ છે.
• રિયલ યુઝર મોનિટરિંગ (RUM) (ફીલ્ડ ડેટા): આમાં વિશ્વભરના તમારા વપરાશકર્તાઓના વાસ્તવિક બ્રાઉઝર્સમાંથી પર્ફોર્મન્સ ડેટા એકત્રિત કરવાનો સમાવેશ થાય છે ("ફીલ્ડ"). RUM સાધનો (જેમ કે Sentry, Datadog, અથવા New Relic) તમારી સાઇટ પર એક નાનો જાવાસ્ક્રિપ્ટ સ્નિપેટનો ઉપયોગ કરીને કોર વેબ વાઇટલ્સ અને અન્ય મેટ્રિક્સ પર રિપોર્ટ કરે છે કારણ કે તે વાસ્તવિક લોકો દ્વારા અનુભવાય છે. તેની તાકાત અસંખ્ય ઉપકરણ અને નેટવર્ક સંયોજનોમાં વૈશ્વિક વપરાશકર્તા અનુભવનું સાચું ચિત્ર પ્રદાન કરવું છે.

બંને પરસ્પર વિશિષ્ટ નથી; તે પૂરક છે. તમારી CI/CD પાઇપલાઇનમાં સિન્થેટિક મોનિટરિંગનો ઉપયોગ કરો જેથી રિગ્રેશન્સને ક્યારેય ડિપ્લોય થતા અટકાવી શકાય. ઉત્પાદનમાં RUM નો ઉપયોગ કરો જેથી તમારા વાસ્તવિક વપરાશકર્તાઓના અનુભવને સમજી શકાય અને સુધારણા માટેના ક્ષેત્રોને ઓળખી શકાય જે તમારા લેબ પરીક્ષણો ચૂકી શકે છે.

તમારી CI/CD પાઇપલાઇનમાં પર્ફોર્મન્સ પ્રોફાઇલિંગનું એકીકરણ

થિયરી મહાન છે, પરંતુ વ્યવહારુ અમલીકરણ જ મહત્વનું છે. ચાલો GitHub Actions વર્કફ્લોમાં Lighthouse CI નો ઉપયોગ કરીને એક સરળ પર્ફોર્મન્સ તપાસ બનાવીએ.

GitHub Actions સાથે એક વ્યવહારુ ઉદાહરણ

આ વર્કફ્લો દરેક પુલ રિક્વેસ્ટ પર ચાલશે. તે એપ્લિકેશનને બિલ્ડ કરે છે, તેની સામે Lighthouse CI ચલાવે છે, અને પરિણામોને પુલ રિક્વેસ્ટ પર ટિપ્પણી તરીકે પોસ્ટ કરે છે.

`.github/workflows/performance-ci.yml` પર એક ફાઇલ બનાવો:

ઉદાહરણ: .github/workflows/performance-ci.yml

• name: પર્ફોર્મન્સ CI
• on: [pull_request]
• jobs:
• lighthouse:
• runs-on: ubuntu-latest
• steps:
• - uses: actions/checkout@v3
• - name: Node.js 20.x નો ઉપયોગ કરો
• uses: actions/setup-node@v3
• with:
• node-version: '20.x'
• cache: 'npm'
• - name: ડિપેન્ડન્સીઝ ઇન્સ્ટોલ કરો
• run: npm ci
• - name: પ્રોડક્શન એસેટ્સ બિલ્ડ કરો
• run: npm run build
• - name: Lighthouse CI ચલાવો
• run: |
• npm install -g @lhci/cli@0.12.x
• lhci autorun
• env:
• LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

આને કામ કરવા માટે, તમારે બે વસ્તુઓની જરૂર છે:

1. તમારા રિપોઝીટરીમાં `lighthouserc.js` ફાઇલ, જે અગાઉના વિભાગમાં બતાવ્યા પ્રમાણે છે.
2. તમારા રિપોઝીટરી પર Lighthouse CI GitHub એપ ઇન્સ્ટોલ કરેલી હોવી જોઈએ. આ Lighthouse CI ને ટિપ્પણીઓ અને સ્ટેટસ ચેક્સ પોસ્ટ કરવાની મંજૂરી આપે છે. ઇન્સ્ટોલેશન દરમિયાન તમને એક ટોકન (`LHCI_GITHUB_APP_TOKEN`) મળશે, જેને તમારે તમારી GitHub રિપોઝીટરી સેટિંગ્સમાં સિક્રેટ તરીકે સાચવવું આવશ્યક છે.

હવે, જ્યારે કોઈ ડેવલપર પુલ રિક્વેસ્ટ ખોલે છે, ત્યારે એક સ્ટેટસ ચેક દેખાશે. જો પર્ફોર્મન્સ બજેટ નિષ્ફળ જાય, તો ચેક લાલ થઈ જશે. લાઇટહાઉસ સ્કોર્સ સાથે એક વિગતવાર ટિપ્પણી પોસ્ટ કરવામાં આવશે, જે બતાવશે કે કયા મેટ્રિક્સમાં રિગ્રેશન થયું છે.

પર્ફોર્મન્સ ડેટાનો સંગ્રહ અને વિઝ્યુઅલાઇઝેશન

જ્યારે `temporary-public-storage` શરૂ કરવા માટે ઉત્તમ છે, લાંબા ગાળાના વિશ્લેષણ માટે, તમે તમારા Lighthouse રિપોર્ટ્સનો સંગ્રહ કરવા માંગશો. Lighthouse CI સર્વર એક મફત, ઓપન-સોર્સ સોલ્યુશન છે જેને તમે જાતે હોસ્ટ કરી શકો છો. તે સમય જતાં પર્ફોર્મન્સ ટ્રેન્ડ્સને વિઝ્યુઅલાઇઝ કરવા, શાખાઓ વચ્ચેના રિપોર્ટ્સની તુલના કરવા, અને ધીમે ધીમે પર્ફોર્મન્સમાં થતા ઘટાડાને ઓળખવા માટે એક ડેશબોર્ડ પ્રદાન કરે છે જે એક જ રનમાં ચૂકી શકાય છે.

તમારા પોતાના સર્વર પર અપલોડ કરવા માટે `lighthouserc.js` ને રૂપરેખાંકિત કરવું સરળ છે. આ ઐતિહાસિક ડેટા તમારી પાઇપલાઇનને એક સરળ દ્વારપાળમાંથી એક શક્તિશાળી વિશ્લેષણ સાધનમાં રૂપાંતરિત કરે છે.

ચેતવણી અને રિપોર્ટિંગ

પઝલનો અંતિમ ભાગ અસરકારક સંચાર છે. નિષ્ફળ બિલ્ડ ત્યારે જ ઉપયોગી છે જો યોગ્ય લોકોને તાત્કાલિક સૂચિત કરવામાં આવે. GitHub સ્ટેટસ ચેક્સ ઉપરાંત, તમારી ટીમના પ્રાથમિક સંચાર ચેનલ, જેમ કે Slack અથવા Microsoft Teams માં ચેતવણીઓ સેટ કરવાનું વિચારો. એક સારી ચેતવણીમાં શામેલ હોવું જોઈએ:

• ચોક્કસ પુલ રિક્વેસ્ટ અથવા કમિટ કે જેના કારણે નિષ્ફળતા થઈ.
• કયા પર્ફોર્મન્સ મેટ્રિક(સે) બજેટનું ઉલ્લંઘન કર્યું અને કેટલું.
• ઊંડાણપૂર્વકના વિશ્લેષણ માટે સંપૂર્ણ Lighthouse રિપોર્ટની સીધી લિંક.

અદ્યતન વ્યૂહરચનાઓ અને વૈશ્વિક વિચારણાઓ

એકવાર તમારી પાસે મૂળભૂત પાઇપલાઇન હોય, પછી તમે તેને તમારા વૈશ્વિક વપરાશકર્તા આધારને વધુ સારી રીતે પ્રતિબિંબિત કરવા માટે વધારી શકો છો.

વિવિધ નેટવર્ક અને CPU પરિસ્થિતિઓનું અનુકરણ કરવું

તમારા વપરાશકર્તાઓ બધા ફાઇબર ઓપ્ટિક કનેક્શન્સ પર હાઇ-એન્ડ પ્રોસેસર્સ સાથે નથી. વધુ વાસ્તવિક પરિસ્થિતિઓમાં પરીક્ષણ કરવું નિર્ણાયક છે. Lighthouse માં બિલ્ટ-ઇન થ્રોટલિંગ છે જે ડિફોલ્ટ રૂપે ધીમા નેટવર્ક અને CPU નું અનુકરણ કરે છે (4G કનેક્શન પર મધ્યમ-સ્તરના મોબાઇલ ઉપકરણનું અનુકરણ).

તમે આ સેટિંગ્સને તમારી Lighthouse રૂપરેખાંકનમાં કસ્ટમાઇઝ કરી શકો છો જેથી વિવિધ પરિસ્થિતિઓનું પરીક્ષણ કરી શકાય, ખાતરી કરીને કે તમારી એપ્લિકેશન ઓછી વિકસિત ઇન્ટરનેટ ઇન્ફ્રાસ્ટ્રક્ચરવાળા બજારોમાં ગ્રાહકો માટે ઉપયોગી રહે છે.

ચોક્કસ વપરાશકર્તા પ્રવાસોનું પ્રોફાઇલિંગ

પ્રારંભિક પેજ લોડ એ વપરાશકર્તા અનુભવનો માત્ર એક ભાગ છે. કાર્ટમાં આઇટમ ઉમેરવા, સર્ચ ફિલ્ટરનો ઉપયોગ કરવા, અથવા ફોર્મ સબમિટ કરવાના પર્ફોર્મન્સનું શું? તમે આ નિર્ણાયક ક્રિયાપ્રતિક્રિયાઓને પ્રોફાઇલ કરવા માટે Playwright અને Lighthouse ની શક્તિને જોડી શકો છો.

એક સામાન્ય પેટર્ન એ છે કે Playwright સ્ક્રિપ્ટનો ઉપયોગ કરીને એપ્લિકેશનને ચોક્કસ સ્થિતિમાં નેવિગેટ કરવું (દા.ત., લોગ ઇન કરવું, કાર્ટમાં આઇટમ્સ ઉમેરવી) અને પછી તે પેજ સ્થિતિ પર તેનું ઓડિટ ચલાવવા માટે Lighthouse ને નિયંત્રણ સોંપવું. આ તમારી એપ્લિકેશનના પર્ફોર્મન્સનું વધુ સર્વગ્રાહી દૃશ્ય પ્રદાન કરે છે.

નિષ્કર્ષ: પર્ફોર્મન્સની સંસ્કૃતિનું નિર્માણ

જાવાસ્ક્રિપ્ટ પર્ફોર્મન્સ મોનિટરિંગને સ્વયંસંચાલિત કરવું એ માત્ર સાધનો અને સ્ક્રિપ્ટો વિશે નથી; તે એક એવી સંસ્કૃતિને પ્રોત્સાહન આપવા વિશે છે જ્યાં પર્ફોર્મન્સ એક સહિયારી જવાબદારી છે. જ્યારે પર્ફોર્મન્સને પ્રથમ-વર્ગની સુવિધા તરીકે ગણવામાં આવે છે, જે માપી શકાય તેવી અને બિન-વાટાઘાટપાત્ર હોય, ત્યારે તે પછીના વિચારને બદલે વિકાસ પ્રક્રિયાનો એક અભિન્ન ભાગ બની જાય છે.

પ્રતિક્રિયાશીલ, મેન્યુઅલ અભિગમથી સક્રિય, સ્વયંસંચાલિત પાઇપલાઇન તરફ જઈને, તમે કેટલાક નિર્ણાયક વ્યવસાયિક ઉદ્દેશ્યો પ્રાપ્ત કરો છો:

• વપરાશકર્તા અનુભવનું રક્ષણ કરો: તમે એક સુરક્ષા નેટ બનાવો છો જે પર્ફોર્મન્સ રિગ્રેશન્સને તમારા વપરાશકર્તાઓને અસર કરતા અટકાવે છે.
• વિકાસની ગતિ વધારો: તાત્કાલિક પ્રતિસાદ આપીને, તમે ડેવલપર્સને સમસ્યાઓ ઝડપથી અને આત્મવિશ્વાસથી સુધારવા માટે સશક્ત બનાવો છો, લાંબા, પીડાદાયક ઓપ્ટિમાઇઝેશન ચક્રને ઘટાડીને.
• ડેટા-આધારિત નિર્ણયો લો: તમે પર્ફોર્મન્સ ટ્રેન્ડ્સનો સમૃદ્ધ ડેટાસેટ બનાવો છો જે આર્કિટેક્ચરલ નિર્ણયોને માર્ગદર્શન આપી શકે છે અને ઓપ્ટિમાઇઝેશનમાં રોકાણને ન્યાયી ઠેરવી શકે છે.

પ્રવાસ નાનો શરૂ થાય છે. તમારી મુખ્ય શાખામાં એક સરળ Lighthouse CI તપાસ ઉમેરીને પ્રારંભ કરો. એક રૂઢિચુસ્ત પર્ફોર્મન્સ બજેટ સેટ કરો. જેમ જેમ તમારી ટીમ પ્રતિસાદ સાથે આરામદાયક બને છે, તેમ તમારું કવરેજ પુલ રિક્વેસ્ટ્સ સુધી વિસ્તૃત કરો, વધુ દાણાદાર મેટ્રિક્સનો પરિચય આપો, અને નિર્ણાયક વપરાશકર્તા પ્રવાસોનું પ્રોફાઇલિંગ શરૂ કરો. પર્ફોર્મન્સ એક સતત પ્રવાસ છે, મંઝિલ નથી. પ્રોએક્ટિવ પાઇપલાઇન બનાવીને, તમે ખાતરી કરો છો કે તમે શિપ કરેલ દરેક કોડની લાઇન તમારા વપરાશકર્તાઓની સૌથી મૂલ્યવાન સંપત્તિ: તેમના સમયનો આદર કરે છે.